Generally, computer systems store data such as computer programs, text documents, graphics, pictures, audio, video, or other information and documents as files that may contain any combination of these kind of information. These files are typically maintained on a hard disk drive associated with a computer but may also be maintained in memory, on floppy drives, remote servers, or other types of mass storage media. To simplify their retrieval, files are generally dispatched among numerous directories or folders. Each directory or folder may have sub-directories or sub-folders. A computer system may contain hundreds of such directories or folders, and file servers, which may be a part of a computer system, may have thousands of such directories or folders. A user generally locates a file by using the file's filename, typically a short character string, e.g. “myphoto.gif”, a disk drive designation and directory or folder may be prepended to the filename, e.g. “C:\photos\myphoto.gif”.
Different types of file systems are available for different operating systems. Each file system type has its own format and set of characteristics such as filename length, maximum file size and so on. For example, on Linux operating system, the most commonly used file system type is the Second Extended File system, also known as ext2fs. It allows filenames up to 256 characters. On Windows (registered trademark of Microsoft Corp.) the VFAT (Windows 95) and FAT32 (Windows 98) file system maximum length of filenames is 255 characters. NTFS and UNIX file system maximum length of filenames is 256 characters.
On the Internet, an addressing scheme is employed to identify resources e.g., HTTP servers, files or programs, and files or HTML documents to display. This addressing scheme is called Uniform Resource Locator (URL). An URL may contain the application protocol to use when accessing the server e.g., “http”, the Internet domain name, also referred to as the server host name, of the site on which the server is running, the port number of the server (the port number may not be specified in the URL but is obtained by translating the server host name), and the location of the resource in the file structure of the server. For example, the URL                http://www.christusrex.org/www2/berry/f6v.htmlspecifies the application protocol “http”, the server host name “www.christusrex.org”, and the server file path to the accessed file “/www2/berry/f6v.html”.        
If the client request is for a file, the HTTP server locates the file and sends it to the client. Depending on the type of file retrieved, the client may activate an application to process the file. Upon reception of a file, the client browser typically examines the extension to determine how to process the file after receipt e.g., launching an application program to process the file. For example, if an HTML document is retrieved, a client's web browser may parse the HTML document and display it. Likewise, if a word processing document is retrieved, the client may activate a word processor to process the document. Alternatively, the accessed file may be saved locally (or downloaded) for a further use.
Most operating systems and file systems do not enable, once a file has been downloaded, to keep track of the relationship between a downloaded or copied file (children) and the source file (parent). For instance, when a file is copied from a network e.g., the Internet, from a server computer to a client computer, the relationship of the copy file on the client computer with the source file on the server computer is lost because the URL of the source file is not recorded with the copied file.
A serious risk associated to the exchange of electronic information on open and unsecured networks, particularly on the Internet, concerns the modification of data during the transfer. As a consequence, it is important to check files received over a network to verify that they have not been corrupted nor altered and/or that they have not been sent by an impostor. It may also be important to keep track of the source files when documents are modified so as to recover the original ones e.g., to analyze modifications.
A file may also have descriptive and referential information i.e., file metadata, associated with it. This information may be relative to the source, content, generation date and place, ownership or copyright notice, central storage location, conditions to use, related documentation, applications associated with the file or services. However, most file systems do not enable to keep a persistent connection of a file with the associated metadata. When a file is transmitted from a computer system to another the connection of that file with associated metadata is frequently lost.
When a user receives a file through a network e.g., by clicking on the icon of a file attached to a received e-mail, he would need to get, apart from the attached file, metadata related with such file. For example, when a file is received from an Internet server, it may be necessary to verify that it has not been corrupted, altered in some manner or to verify that it has been received from the proper sender rather than by an impostor. Particularly, if the received file is a software program, it could be of the utmost importance to ensure that received file has been sent by a trustworthy party prior exposing the computer system to a program file that might include a “Trojan Horse” or that could infect the user's computer with a virus. To that aim, the user may require to access file metadata, particularly a digital certificate and digital signature, to verify the authenticity and integrity of the file before executing it.
Today there are different approaches for implementing the association of a file with metadata of that file. Basically, metadata of a file can be encoded onto the same filename of the file, they can be prepended or appended onto the file as part of a file wrapper structure, they can be embedded at a well-defined convenient point elsewhere within the file, or they can be created as an entirely separate file. Each approach has inherent advantages and disadvantages:                naming a file so that the filename encodes metadata is possible in theory but, while an attempt may be made to make a filename descriptive, it is generally impossible to provide an adequate description of a file on a filename due to filename length restrictions.        wrapping a file with delimiters and prepending or appending metadata at the beginning or the end of the file is convenient (as both the file and the metadata travel together) and algorithms to extract the metadata encoded in this way are simple and efficient. Conversely, wrapper and metadata must generally have to be removed before the file can be used as originally intended. For this reason, metadata analysis typically only occurs when the file is retrieved. If the file is later passed on or moved, metadata would be lost. Another limitation of metadata wrapping methods is the incompatibility of those methods with standard types of files and file formats that prevents their use for encoding metadata on many types of files such as image, video, audio or executable files.        embedding metadata onto the digital representation of files is described in publication entitled “Techniques for data hiding” by W. Bender and al. IBM Systems Journal, Vol. 35, Nos 3&4, 1996. The most common form of high bit-rate encoding on images is the replacement of the least significant luminance bits of image with the embedded data. This technique is imperceptible (the alteration of the image is not noticeable) and may serve various purposes, including watermarking or tamper-proofing. Since metadata is embedded in the file, metadata extraction could be done during file retrieval, each time the file is rendered, or at any other arbitrary time post-receipt. The greatest limitations of such data embedding methods are a lack of current standardization about how (and where) to integrate metadata into the many different possible types of files and file formats, particularly on image, video, audio or executable files, and the added complexity of algorithms to extract metadata from files encoded in many different ways. Another drawback of this solution is that embedded metadata would affect the readability of documents or downgrade the quality of digital images.        maintaining metafiles separately e.g., on a server, from related files has the advantage of supporting metafile access, however the address of the metafile (being itself metadata of the file) must be known in advance or must be determined in some way from the file A well known solution consists in relating the metafile filename to the filename of the associated file using some lexicographic rule e.g., using a different file extension. If some applications use filename conventions to associate files with metafiles produced by those applications, filenames for the associated files (or metafiles) may be cryptic, and may be significant only to the application. Another important drawback is that the association of the file with the metafile may be lost when the file is transmitted to a different system e.g., through a network.        
As a conclusion, there is a need for a method and systems for creating hyperlinks from a main file to target files, that could be either source or other associated files.